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ABSTRACT 



A FormLogic (FL) client/server system and method to 
access existing enterprise data sources on an occasional 
basis. The system includes a FL builder program to generate 
a communications agent that encapsulates a communication 
session. The session includes one or more related tasks. The 
system also includes a FL server which is connected to one 
or more enterprise data sources. The FL server provides the 
ability to link hardware devices running a FL engine as a 
client to access existing enterprise data sources on an 
occasional basis. It is optimized to communicate by 
exchanging a minimum amount of data, since the wireless 
transports do not move large amounts of data quickly and 
data is expensive to move. Each session encompasses con- 
necting the remote host, performing a specific task or set of 
tasks, then disconnecting from the host. Because the con- 
nection times must be short, the client and server need to be 
able to perform the required tasks without user intervention. 
The FL engine includes a user interface, a script engine, a 
communications module, and a local data store, and prefer- 
ably runs on a mobile personal digital assistant. Upon 
connection, this local database is automatically manipulated 
by the FL server. The FL server can query the FL client 
database, add data to the client database, or remove data 
from the client database so as to make updates to both the 
client and server databases for reflecting changes that have 
happened on both sides since the last connection. 

19 Claims, 5 Drawing Sheets 
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ENTERPRISE CONNECTIVITY TO 
HANDHELD DEVICES 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 5 
The present invention generally relates to client/server 

technology and, more specifically, to a client/server archi- 
tecture for occasional connections between mobile comput- 
ing devices and enterprise computing systems, 10 

2, Background 

In the current persistent connection client/server model, 
personal computer clients "connect" to a server on the 
network and request data from the server as needed by an 
application. This is usually performed by use of SQL 15 
(Structured Query Language). The connection between the 
client and server exists the entire time the application is in 
use, usually for hours at a time. This is not possible in a 
mobile model, because it is not possible for mobile clients 
to remain connected for that amount of time. Mobile clients 20 
connect on an occasional basis, and when they do connect, 
the connection needs to move the smallest amount of data in 
the least amount of time. This is because wireless transports 
are not capable of moving large of amounts of data quickly, 
and data is extremely expensive to move. 25 

Existing client/server technologies based on persistent 
network connections were not designed to support occa- 
sional connections between low performance, low overhead 
handheld computing devices and existing enterprise com- 
puting systems. What is needed is a client/server architecture 30 
that supports occasional connections between low 
performance, low overhead mobile computing devices and 
existing enterprise computing systems. What is desired is an 
application development and deployment platform, such that 
developers have the ability to create applications using a 35 
series of forms, tables, and communications agents, and the 
ability to deploy and maintain these applications. This 
platform should be implemented using an object model that 
can be easily ported to other hardware platforms and oper- 
ating systems. 40 

An architecture that allows multiple devices to connect 
concurrently to a single server is desired. This architecture 
should allow developers to connect any existing enterprise 
data source to handheld clients in the field. This architecture 45 
should allow developers to create two way links between 
any existing enterprise data source on a network, such as a 
database, mail server, or internet news feed, and FormLogic 
client applications. 

The improved client/server architecture should provide 50 
"transport independence", which is a unique requirement of 
field based applications. Sometimes it is necessary to con- 
nect over a serial cable, other times over a wireless local area 
network (LAN), and other times over the Internet. Such 
functionality has been addressed with "middleware" prod- 55 
ucts. However, middleware products usually consist only of 
a series of "C" application programming interfaces (APIs) 
on client and server ends that require the developer to 
integrate them into an application. What is desired is to 
integrate "middleware" functionality directly into a specific 60 
server structure for which developers create "services". 

Existing client/server APIs move a tremendous amount of 
data, such as Microsoft™'s ODBC (Open Database 
Connectivity). It is not feasible to use interfaces such as 
ODBC in the handheld or occasionally connected environ- 65 
ment for two reasons. 1) The code size of ODBC is several 
megabytes — more than the entire memory of today's hand- 
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held devices and 2) ODBC is designed to work over a 
persistent connection with high bandwidth, such as Ethernet. 
Therefore, what is desired is a set of client/server APIs that 
can utilize a variety of transports to move a minimum 
amount of data over the wire or through the airways. To 
accommodate current and future transports, a message- 
based asynchronous communications protocol that is 
designed to work efficiently over low bandwidth, high 
latency networks is needed. This capability is required for 
evolving wireless transports, such as these provided by the 
companies of ARDIS™, RAM Mobile Data™, and 2-way 
paging, such that developers will automatically be able to 
support them without making any changes to their applica- 
tions. 

Application software on a client device may not be the 
most recent available due to enhancements, fixes, and so 
forth. The architecture should support a users and groups 
model, wherein different applications modules can be dis- 
tributed to a particular user or group. Using a version control 
for these applications components, users can automatically 
be updated with the latest version of an application upon 
connection. 

SUMMARY OF THE INVENTION 

The client/server (C/S) architecture of the present inven- 
tion is designed to allow the client to become a direct 
extension of the corporate data sources. The C/S compo- 
nents use an object management scheme and are preferably 
based on Microsoft™*s OLE technology. A 32 bit OLE 
control (OCX) is used to manage a connection with a 
multiple mobile personal digital assistant (PDA). This archi- 
tecture allows the developer to manage a single connection 
with a single PDA device. It provides a completely asyn- 
chronous communications interface, providing multiple 
connections with multiple devices at the same time. Appli- 
cations built with existing development tools can be enabled 
to either exchange data on demand, or provide facilities for 
a multi-port server allowing remote database access and 
e-mail access from the field. When used with client/server 
development tools such as Visual Basic™, this server object 
allows developers to create direct connections between PDA 
devices, and nearly any host data source, including 
databases, mail servers, and Internet data sources. 

In one aspect of the present invention there is a client/ 
server system, comprising a portable client computer, com- 
prising a client database, and a communications module; a 
server computer, comprising a server data source, a session 
module, in communication with the server data source, to 
non-persistently connect to the communications module and 
access the client database from time to time. 

In another aspect of the present invention there is, in a 
computer network, including a server, a data source, and a 
mobile client having a database, a method of synchronizing 
the client database and data source during a non-persistent 
connection, the method comprising the steps of connecting 
the mobile client to the server; manipulating the client 
database by the server; updating the data source responsive 
to the manipulation by the server; and disconnecting the 
client from the server, 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram of an exemplary known 
client/server system; 

FIG. 2 is a high-level block diagram of a preferred 
client/server embodiment of the present invention; 

FIG. 3 is a block diagram of the architecture of client 
components and server components of the system shown in 
FIG. 2; and 
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FIGS. 4a and 4b are a diagram showing an exemplary 
client/server message exchange for a mail exchange session. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

The following detailed description of the preferred 
embodiments presents a description of certain specific 
embodiments to assist in understanding the claims. 
However, the present invention can be embodied in a 
multitude of different ways as defined and covered by the 
claims. Reference is now made to the drawings wherein like 
numerals refer to like parts throughout. 

The new FormLogic client/server (C/S) architecture is 
designed to allow a FormLogic client to become a direct 
extension of the corporate database. Previously, as described 
in applicant's copending patent application, now U.S. Pat. 
No. 5,704,029, FormLogic clients provided data to host 
databases in the form of ASCII files that had to be imported 
into the target database. While reliable for batch file 
processing, this method did not provide a direct link between 
the client personal digital assistant (PDA) and the enterprise 
database. Furthermore, there was no way to automatically 
extract records from the enterprise database, and send them 
to the device. The new FormLogic C/S architecture over- 
comes these limitations by allowing developers to create 
direct links between PDAs and enterprise data sources using 
industry standard development tools. 

The new FormLogic client/server components described 
herein use an object management scheme and are preferably 
based on Microsoft™^ OLE technology. A 32 bit OLE 
control (OCX) is used to manage a connection with a 
multiple PDA device. Because this OCX component is 
based on the industry standard component software model, 
it can be used with all leading industry standard develop- 
ment tools including Lotus Notes™, Microsoft Visual 
Basic™, Microsoft Access™, Microsoft Visual FoxPro™, 
Borland Delphi™ and PowerBuilder™. The OLE imple- 
mentation also provides the developer with a familiar object 
model and programming interface for integrating PDA tech- 
nology into a predominantly Windows™ -based computing 
infrastructure. This allows developers to create PDA-based 
solutions using their existing development tools, avoiding 
the need to develop for proprietary PDA operating systems. 

A key component of the FormLogic client/server archi- 
tecture is the FormLogic service object. The FormLogic 
service object allows developers to link PDA client appli- 
cations for an unlimited number of user connections over a 
variety of transports without the need to worry about multi- 
user and concurrency issues. The service object allows the 
developers to write the application as if it were communi- 
cating with a single client, allowing them to focus on the 
application itself, rather than focus on communications 
transport, multi user, and concurrency issues. 

The FormLogic service object has the following features: 

Ability to retrieve specific records based on a query; 

Ability to programmatically build and send records to the 
FormLogic Client; 

Ability to send asynchronous messages between the Cli- 
ents and Server; 

Support for direct serial and modem connections; 

Support for AppieTalk™ (ADSP) and Internet (TCP/IP) 
network connections; 

OCX (ActiveX) implementation allowing integration 
with a host of development tools; 

Ability to customize the FormLogic Client Connection 
dialog during connections; 
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MD5 authentication with the FormLogic Client; 

Complete Software Distribution interface allowing devel- 
opers to programmatically install FormLogic forms, agents 
and tables during connections; 
5 100% asynchronous interface. 

A variety of applications are possible for the new Form- 
Logic client/server architecture. Several exemplary applica- 
tions are described below: 

Provide Real-Time Access to Corporate Databases - Prob- 
10 ably the most exciting use of the FormLogic C/S archi- 
tecture is the integration of PDA technology with enter- 
prise computing environments. Developers can now build 
applications that allow PDA devices to connect to virtu- 
ally any type of database, from Microsoft Access™ to 
15 Oracle™, or even legacy systems. Once connected, devel- 
opers can create applications that can query as well as 
update the database. For example, this allows for 
extremely fast development of field service applications, 
wherein field personnel connect to a remote database to 
20 retrieve work orders, and then later update the same work 
orders. 

Create Robust E-mail Gateways - Using existing OLE 
controls from third parties, developers can easily integrate 
existing Messaging API-based or point-of-presence 
25 (POP)/Simple Mail Transfer Protocol (SMTP) mail sys- 
tems. This provides opportunities for developers seeking 
to provide an application that provides access to both a 
host database and an enterprise e-mail system in a single 
connection. 

30 Create Sophisticated Servers - Because the FormLogic Con- 
nection object is based on the OLE component 
technology, developers can create applications that host 
multiple simultaneous connections with a minimum 
amount of effort. Existing applications created with tools 
35 such as Microsoft Access™, can quickly be turned into 
servers capable of hosting numerous simultaneous con- 
nections to PDA devices in the field. 
Integrate PDA Data Transfer Functionality Into Existing 
Applications - Existing applications can easily be modi- 
40 fied to provide simple data exchange facilities with PDA 
devices. This allows portions of databases to be carried 
into the field where they can be modified and later 
synchronized with the server database. 
Referring to FIG. 1, a typical client/server (C/S) system 
45 100 previously known in software technology is shown. The 
system 100 includes a database 102, one or more servers 
104, such as a mail server 104', and a local area network 
(LAN) 106. Alternatively, the LAN could be a wide area 
network (WAN) or an intranet. The database 102, the servers 
50 104 and the LAN 106 collectively are known as the server 
portion 107 of the client/server system. Aplurality of clients, 
such as personal digital assistants (PDAs) 108, 110 and 112, 
are in communication with the server portion 107. The 
communication may be over a direct serial link, such as a 
55 serial cable or a modem. 

In a traditional persistent connection based client/server 
model, clients remain connected and request data from the 
server as they need it. As the data is requested it is stored 
locally for manipulation and then discarded. The server still 
60 remains the primary and only main storage area for the data 
because the client always has access to it when needed. 

Referring to FIG. 2, a client/server -system 130 of the 
present invention will be described. The client/server system 
130 hereinafter may also be referred to as the FormLogic 
65 client/server system. The system 130 includes the database 
102, the mail server 104',the LAN 106 and an administrator 
server 148. This portion 107' is similar to the server portion 
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107 of FIG. 1. However, a FormLogic (FL) server 132 is server 132 since the last connection. The client database 172 

connected to the LAN 106 in a persistent fashion to provide serves as a temporary representation of the host database, 

advantages not possible with the traditional system 100. The e.g., 180, because the client cannot maintain a full-time 

FL server 132 is connected to a plurality of client sub- connection to the FL server 132. On the server side, a 

systems. For example, modems 134 and 134' interconnect 5 Remote Database API has been developed that allows devel- 

the FL server 132 and PDA clients 136 and 136', respec- opens to efficiently manipulate the client database 172 while 

tively. An intranet or the Internet interconnects the FL server sending a minimum amount of data over the connection, 

132 and clients 142 and 142'. Client devices 146 and 146* are FL Server 

directly connected to the FL server 132 by a serial cable 147, The implementation of the FormLogic Server architecture 

for example. 10 is unique. To allow the FL server 132 access to any data 

Referring to FIG. 3, the architecture of the FormLogic source a developer may already be working with, an API is 

server 132 and a representative FormLogic client 136 will be provided between those existing data sources, e.g., 180, 182, 

described. The FL server and FL client were introduced in and the FL server 132. The FL server 132 comprises an OCX 

conjunction with FIG. 2. (Microsoft™ OLE Custom Control), or software 

FL Client 15 component, that can be embedded in a variety of existing 

The FL client 136 includes an FL Engine 160 which development tools, including those tools that are already 

allows FormLogic applications to execute on a variety of being used by developers to access enterprise data sources 

handheld devices. The FL Engine 160 preferably runs on an (e.g., MS Visual Basic™, PowerBuilder™, Delphi™, Visual 

Apple® McssagcPad® Model 120 or Model 130 PDA using C++™). This allows developers to easily extend the FL 

the Newton® version 2.0 operating system software. Of 20 server 132 to their data sources using tools they are already 

course, other portable computer devices and operating sys- familiar with. 

tern software, such as Magic Cap™ from General Magic™ The FL server 132 provides the ability to link hardware 

or Pegasus™ from Microsoft™ Corporation, can be used in devices running the FL Engine 160 to access existing 

other embodiments. The FL Engine 160 is, in simple terms, enterprise data sources on an occasional basis. It is opti- 

a hardware independent virtual machine that allows a single 25 mized to communicate by exchanging a minimum amount of 

application to work on various hardware platforms. A simi- data, since the wireless transports are expensive and are 

lar example is the Java virtual machine, licensed by Sun characterized by high latency and low bandwidth. The 

Microsystems™, which may or may not execute within the FormLogic Server 132 serves as a "gateway" between 

context of a browser. FormLogic Clients (e.g., 136, 142, 146) and enterprise data 

The FL client subsystem 136 preferably includes the FL 30 sources (e.g., 180, 182). The server 132 supports what is 

Engine 160 comprising a user interface (UI) 162, a script known as a multi-tier client/server model in that it creates an 

engine 164, a communications module 166, and a data store intermediate server between the client and the "traditional" 

168. The user interface (UI) 162 and the script engine 164 or "original" server. 

have been previously described in applicant's copending The FL Builder (not shown) is a development tool, 

patent application, now U.S. Pat. No. 5,204,029, which is 35 previously described in applicant's copending patent 

hereby incorporated by reference. The communication mod- application, now U.S. Pat. No. 5,704,029, used to build 

ule 166 packages data that is either being received or sent by FormLogic applications that can be executed on a variety of 

the FL Engine 160 and handles interfacing the FL Engine to hardware platforms. It is designed to give developers the 

the FL Server 132 through the modem 134, the Internet 140 look and feel of existing development tools, preferably 

or the direct serial connection 147. Another embodiment 40 Microsoft Visual Basic™, while at the same time introduc- 

may include a wireless LAN. The data store 168 includes ing some innovative features. It is a WYSIWYG tool that 

one or more application programs 170 and a remote database allows one to write code. It is unique in that it allows 

172 for storing the results of running the application pro- developers to create an object called a "communications 

gram or storing data received from the FL Server 132, for agent" or just "agent" that encapsulates a communications 

example. 45 "session". 

Because FormLogic clients, e.g., 136, do not maintain Because mobile clients cannot maintain a persistent con- 
persistent connections with the FL server 132, they need to nection to the FL server 132, they must "connect" for short 
be able to store and access information while not connected periods of time to perform a specified operation or set of 
to the host database, e.g., 182, or other data source. The FL operations. Each of these connections is referred to as a 
Engine 160 incorporates a full local database implementa- 50 "session", during which time a specified set of operations are 
tion that allows data to be manipulated and collected by the . performed between the FL client and FL server. Examples of 
FL client while not connected to the FL server 132, Upon these sessions include connecting to retrieve work orders, 
connection, this local database 172 is automatically manipu- checking inventory on a product, or retrieving a monthly 
lated by the FL server 132. The FL server 132 can query the price list update. Each "session" encompasses connecting 
client database 172, add data to the client database, or 55 the remote host, performing a specific task or set of tasks, 
remove data from the client database in order make updates and then disconnecting from the host. Because the connec- 
to both the client and server databases to reflect changes that tion times must be short, the FL client and FL server need to 
have happened on both sides since the last connection. Thus, be able to perform the required tasks without user interven- 
a synchronization of the two databases is performed. tion. This is very different from a persistent connection 

In the FormLogic C/S model, the FL server 132 maintains 60 based client/server model where the connection exists the 

the primary enterprise database, e.g., 180, but instead of entire time the application is used, and data is only retrieved 

maintaining a full-time connection with clients, clients con- when the user requests it. 

nect on an occasional basis. During this connection, the FL Communications agents, also just known as "agents", are 
server 132 is responsible for manipulation of the FL client developed to describe the communications "session". Corn- 
database 172, including retrieving data that has been col- 65 munications agents know how to connect to a particular 
lected by the client since the last connection, or inserting host, perform a set of operations or tasks, which usually 
new data in the database that has been added on the FL includes synchronizing the host data source, e.g., 180, with 



05/27/2004, EAST Version: 1.4.1 



5,857,201 

7 8 

the client database 172, and then disconnecting. The idea is existing enterprise data sources without worrying about 

that a developer can create a communications agent that multi-user and concurrency issues. The FL Server APIs are 

represents each of the communications sessions that a field used from within Visual Basic or other development tools to 

user may need. For example, there may be a communica- communicate with FL Engine and allow server applications 

tions agent that retrieves work orders, updates work orders, 5 f or an unlimited number of user connections over a variety 

or downloads a price list. There may also be a communica- of transports without the need to worry about multi-user and 

lions agent that simply checks inventory on a particular concurrency issues. The server object allows the developers 

product. In general communications agents are designed to t0 ^ the application ^ if it were communicating with a 

encompass the fundamental operations that are needed to ^ cU ^ them ^ Qn ^ ^ for 

exchange data between a client and a host for a particular „ n 4l% r f . - 4 nf tU *u e ■ *• 

aooli cation r 10 the application itself, rather than focus on communications 

The agent implementation is simple, and utilizes a simple tra f P ort ' multi-user, and concurrency issues, 

software "object" to describe the agent. The developer Service * ethods »" [™** b * services ' usu *Hy with the 

creates a named object and provides a name, as well as other convention connobj.MethodO". Some methods such as of 

properties, which, upon connection, tell the FL server what lhe remote database APIs have corresponding events that are 

type of session the FL client is requesting, as well as any 15 triggered by the messages from the client indicating the 

parameters required to perform specific operations in that results of the actions invoked by the method, 

session. Agents may also specify a particular transport to The Service APIs fall into three distinct categories: the 

minimize the cost of a connection, e.g., an agent needing a Remote Database APIs, the Messaging APIs, and Utility 

long connection time would use a less expensive type of APIs: 

transport. 20 Remote Database APIs 

An exemplary Session 1 200 called Daily Connect These calls are used to directly manipulate the client 

includes three tasks: Taskl 204, e.g., GetMail; Task2 206, database during a connection. When invoking Remote Data- 

e.g., SendMail; and Task3 208, e.g., Updatelnventory. base APIs from services, corresponding events will be 

Another exemplary Session2 202 includes two tasks: Task4 passed back to the services that generated the call. A remote 

210, e.g., Interrogatelnventory; and Task2 206, SendMail. 25 procedure call mechanism is used. There is a corresponding 

The FL Server 132 includes a message handler 184 for event for every Remote Database API. Corresponding 

interfacing the FL Server 132 to the FL Engine 160 through events are guaranteed to be called, assuming the method 

the modem 134, the Internet 140 or the direct serial con- used to trigger it did not return an error. Methods and Events 

nection 147, for example. The message handler 184 com- for the Remote Database APIs are listed in Table 1 below, 

municates with each instantiation of the FormLogic Con- 30 
nection object. For example, as shown in FIG. 3, a 
Connection object 194 may be associated with Client A 136 
and a Connection object 196 may be associated with Client 
C 146. Each of these connections are independent, and a 

plurality of connections may be concurrent. Each Connec- 35 
tion object has a current task pointer for pointing to the 
current task. When the task is completed, the pointer is 
incremented to point to the next task in the session. Each of 
the Connection objects is pointing to a particular task in a 

particular session. In FIG. 3, for example, Connection object 40 
194 is pointing to Sessionl and Connection object 196 is 
pointing to Session2. There is one real object for each 
session, and each connection points to its current place (task) 
in the session. 

A set of tasks are provided or handled by a service. A 45 
service defines the relationship between a client application 

and an enterprise data source. Examples of services include Method details and Event details for the Remote Database 

Mail, World Wide Web Gateway, or Inventory. For example, APIs are listed in Table 2 below, 
a Mail service 190 is a service that provides the Getail task 

204 and SendMail task 206, and is connected to the data 50 TABLE 2 

source 180. An Inventory service 192 provides the Update- 

Inventory task 208 and Interrogatelnventory task 210, and is CreateRecordSet(^bleName queryDef, RSName) 

J . A . j „ . RSName String User defined recordSet name, 

connected to an inventory data source 182, for example. tableName String Name of table on FormLogic Client. 

Each Connection object has its own iastantiation of the queryDef String SQL "Where" clause 

service class associated with it. For example, Taskl and 55 returns errcode 

Task2 comprise an instantiation of Servicel for Connection GetN C xtR e cord(RSName) 

i • ^ • - . . RSName String User defined recordSet name. 

object 194. The service is written as if the server was in returns errcode 

communication with a single client. Multiple copies of the AddRecord(RSName, FLRec) 

service are needed for each single Client connection coming RSName String User defined recordSet name. 

into the FL server. Each instantiation of the service does not 60 ^ . ^ Rccord 0b J cct Rccord to scnd t0 FormL *s ic Clicnt - 

. , „ returns errcode 

maintain connection to its data source; only the "master* DeieteRecordCRSName, FLRec) 

service Object maintains connection to the associated data RSName String User defined recordSet name, 

source. The service instantiations can be considered as FLRec FL Record Object Record to send to FormLogic Client. 

interfaces between the "master** service and the connection. I! 1 ^ c " code Jf , , . ^ T 

„ OnCreateRecordSet(errcode, RSName, recordCount) 

rL server APIs 65 errcode j^g Error code. 

The FL Server APIs allow developers to write services for RSName String User defined recordSet name 

FL Server that will link FonmLogic client applications to 



TABLE 1 


Method 


Corresponding Event 


CreateRecordSet (RSName, tableName, 


OnCreateRecordSet 


queryDef) 




GetNextRecord (RSName) 


OnGetNextRecord 


AddRecord (RSName, FLRec) 


OnAddRecord 


Delete Record (RSName, FLRec) 


OnDeleteRecord 


DeleteRecordSet (RSName) 


On DeleteRecordSet 


Event 




OnCreateRecordSet (errcode, RSName, 




recordCount) 




OnGetNextRecord (errcode, RSName, record) 




OnAddRecord (errcode, RSName) 




OnDeleteRecord (errcode, RSName) 




OnDeleteRecordSetferrcode, RSName) 
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TABLE 2-continued 



recordCount Long Number of records in RSName 

record Set 

OnGetNextRecord(errcode, RSName, FLRec) 
errcode Long Error code. 

RSName String User defined recordSet name 

FLRec FL Record Object Record received from FormLogic 

Client. 

OnAddRecord (errcode RSName) 

errcode Long Error code. 

RSName String User defined recordSet name 

OnDeleteRecord (errcode, RSName) 

errcode Long Error code. 

RSName String User defined recordSet name 



Messaging APIs 

These APIs are used to send specific messages to Form- 
Logic Agents 170 (FIG. 3) on the client device. A rules- 
based specification of a particular agent on the client can be 
done. Messages can be used to send any type of data in real 
time, and allows the agent on the client side to decide how 
to handle it. Virtual sessions can be established with these 
APIs. Methods and Events for the Messaging APIs are listed 
in Table 3 below. 

TABLE 3 



Method 

Send 
Reply 
Event 

OnMessage 



Method details and Event details for the Messaging APIs are 
listed in Table 4 below. 



Send(agentlD, methID, message) 

agentID Long Client agent ID 

methID Long Developer denned method ID 

message FL Record Object Record to send to FormLogic Client. 

returns errcode 

Reply(agentID, methID, message) 

agentID Long Client agent ID 

methID Long Developer defined method ID 

message FL Record Object Record to receive from FormLogic 

Client. 

returns errcode 

OnMessage(errcode, objID, methID, FLRec) 

errcode Long Error code. 

objID Long User defined object ID 

methID String User defined method ID 

FLRec FL Record Object Record to send to FormLogic Client. 



Utility APIs 

Utility APIs don't actually send any data between the 
server and the client. They are used to perform functions 
such as setting timers, writing to the system log, and 
controlling the client's connection dialog. Methods and 
Events for the Utility APIs are listed in Table 5 below. 

TABLE 5 



Method 

SetTimer (Name, interval) 

Log En try (messagetype, message) 

SetStatus (message, gaugeType, currVal) 

GetUsername ( ) 

GetAgentParm (parmName) 

StartNextTask 



TABLE 5-continued 

Event 

OnTimcr (encode, RSName) 



Method details for the Utility APIs are listed in Table 6 
below. 

TABLE 6 

LogEntry(messagetype, message) 

messagetype Integer Message type 

message String Text message 

returns errcode 

SetStatus(message, gaugeType, currMil) 

message String Text message 

gaugeType Integer kProgressbar = 0, kBarberPole «■ 1 

currVal Integer Gauge position between 0 and 100. 

returns errcode 



20 The LogEntry method provides the ability to write to the 
system log when a selected activity occurs, e.g., when the 
user logs on or off. Error messages can be written to the 
system log specific to a particular service that the developer 
is writing. The system log can be read by the system 

25 administrator. This method could be used for billing clients. 
For example, a log entry could be made every time a 
message is read from a news feed service. 

The SetStatus method gives the FL server a means to 
update a dialog box on the client side without causing an 

3Q extra message to be sent over the link, i.e., this method does 
not generate additional traffic on the link. The update mes- 
sage is jammed into the next message or packet that is being 
sent. 

The SetTimer method provides a way to determine if the 
client has responded. The developer can set an alarm time 

35 interval and an alarm timer name to measure elapsed time. 
After the alarm is triggered, an OnTimer Event is fired with 
the name of the alarm timer. This method is used to prevent 
code block or lockup, and is used in place of a timeout 
because different transports take different amounts of time to 

40 respond. 

The GetUsername method can be used inside the service 
to obtain the name of a logged-on user. 

The GetAgentParm method allows a service to extract any 
of the parameters sent over to the FL server at log-on time, 

45 For example, a Mail agent may pass over a log-on name, a 
password and a mail server ID. The FL server stores these 
parameters for the developer to use inside the service. In the 
current example, the developer could use the internet pro- 
tocol (IP) address of the mail server inside the service. 

50 The StartNextTask method is used by the developer to 
execute the next task after the current task is completed. 
After StartNextTask is called, the FL server takes over and 
automatically gets and executes the next task in the session. 
Example Client/Server Message Exchange 

55 Referring to FIGS. 4a and 4b, an exemplary client/server 
message exchange for a Mail Exchange session 230 will be 
described. The exchange between the FL client 136 and the 
FL server 132 is shown in a graphical time dependent 
format. Time increases while traversing downward on the 

60 graph. 

The session shown in FIGS. 4a and 4b illustrates a single 
service. Of course, other services could be part of a single 
session. The session shown in FIGS. 4a and 4b shows Taskl 
(204) and Task2 (206) of Sessionl (200). Task3 (208) is not 
65 shown in this session. 

The session 230 begins with a user initiating a login 232. 
A message 234 passes a username of the user, the user's 
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password, an application profile, and a session name to the event 274. The server checks every event to determine if an 

server. The application profile is a client list of all its error code is included, and if so, takes appropriate action, 

applications and includes forms, agents, tables and respec- Every method also returns an error code that is also checked, 

tive version numbers. The server maintains an administra- A second AddRecord method 276 and a second OnAd- 

tion profile which is a list of the most current applications 5 dRecord event 278 are performed for a second FL record 

and the version numbers of the applications and their forms, object sent to the client. 

agents and tables. A SelStatus method (not shown) of the Utility APIs is 

The server authenticates 236 the received data from the called after each GetNextRecord method and each 

message 234, i.e., the received username and password are AddRecord method to update a progress thermometer in a 

verified as correct. In response, the server sends the time of dialog, for example. At the completion of the OnAddRecord 

authentication 238 to the client. The server also checks the event 278, the server calls a Send method 280 to send a 

application profile received from the client against its dialog message in a dialog box on the video screen of the 

administration profile to determine if the client applications client, such as "2 mail records sent, 2 mail records received", 

are current as determined from the version numbers. If any The server 132 then invokes a disconnect task 290 by a 

applications are not current, a synchronize software opera- Disconnect method 292. In the presently preferred 

tion 240 is initiated by the server to update the client 15 embodiment, the client disconnects and responds with a 

machine. The most current application(s) are then sent over OnDisconnect event 294 to the server. In another 

to the client using a handshaking mechanism. Since FL embodiment, the client does not respond with the OnDis- 

application and updates are relatively small, this process connect event 294, but does perform the disconnect house - 

should complete rather quickly. keeping task. 

At the completion of the software synchronization 240, 20 While the above detailed description has shown, 

the server accesses the exemplary ExchangeMail session. described, and pointed out the fundamental novel features of 

StartNextTask 250 is automatically called by the server for the invention as applied to various embodiments, it will be 

the first task (GetMail) in the session. A CreateRecordSet understood that various omissions and substitutions and 

method 252 (Remote Database API) is invoked by the changes in the form and details of the system illustrated may 

server. A recordSet object represents a plurality of records in 25 be ma f e b y those skilled in the art, without departing from 

a base table or the records that result from running a query. lhe s P irit t of th t e invention. 

In this instance, the name of the recordSet is "Mail" and the What is claimed is: 

"_direction=' outgoing"' string is a query that identifies A data synchronization system for a portable client 

records in the Mail table for which the direction is outgoing. computer, comprising: 

The communication module 166 at the client creates a set of 30 a data storage; 

records on the client device in response to the message 252. a gateway computer having a persistent connection with 

It also sends an OnCreate RecordSet event 254 to the server. the data storage, the gateway computer comprising a 

The recordSet name ("Mail") and a recordCount, which is session module in communication with the data storage 

the number of records in the recordSet, e.g., two pieces of for retrieving data, removing data, or updating data in 

outgoing mail, are returned to the server. 35 the data storage and wherein the data storage resides on 

The server then utilizes the GetNextRecord method 256 to a network that is further connected to the gateway 

retrieve the first record from the "Mail" recordSet. The computer; and 

communication module 166 at the client responds with an a portable client computer, comprising: 

event which is received by OnGetNextRecord 258 at the a client database, and 

server. The recordSet name ("Mail") and a FL record object 40 a communications module capable of establishing a 

(the Record), are returned to the server. The FL record object non-persistent connection to the gateway computer 

is an object of type FL record that encapsulates a set of fields and allowing access to the client database from time 

and their values. In this instance the results are sent to mail to time for synchronization of at least a portion of the 

server, but could also be sent to a printer, a screen display, data in the client database. 

or to a database, for example. In the preferred embodiment, 45 2. The system of claim 1, wherein the access to the client 

after the record is received at the server, the record is deleted database from the gateway computer is a query, 

at the client. In another embodiment, the record is main- 3. The system of claim 1, wherein the access to the client 

tained at the client. The second outgoing mail record is database from the gateway computer is to add data to the 

retrieved by a second GetNextRecord method 260 and client database. 

OnGetNextRecord event 262. At the completion of event 50 4. The system of claim 1, wherein the access to the client 

262, both pieces of mail have been retrieved from the client database from the gateway computer is to remove data from 

by the server. Continuing the session 230 on FIG. 4b, the the client database. 

session calls StartNextTask 270 to invoke a SendMail task. 5. The system of claim 1, wherein a portion of the client 

The server utilizes an AddRecord method 272 to send mail database is retrieved and stored in the data storage, 

to the client. The recordSet name ("Mail") and the FL record 55 6. The system of claim 1, wherein the network is a wide 

object (the Record), are passed to the client. The mail server area network. 

or other source of data is interrogated to determine the data 7. The system of claim 6, wherein the wide area network 

to be sent to the client. This example assumes that the is the Internet. 

recordSet is available from the previous GetMail task and 8. The system of claim 1, additionally comprising an 

that the SendMail task is done after GetMail. Alternatively, 60 application program running on the portable client 

a CreateRecordSet method could be invoked at the begin- computer, wherein the application program results in 

ning of the SendMail task (before AddRecord). Using a flag changes to the client database. 

or other indicator, a check could be done to determine if the 9. The system of claim 8, wherein the application program 

recordSet is already created, and if not, the CreateRecordSet is for completing electronic forms. 

method would be invoked. 65 10. The system of claim 1, wherein the data storage 

The client receives the FL record object (the Record) and comprises a mail server so that the client computer can 

responds to the AddRecord method with an OnAddRecord access electronic mail. 
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11. In a computer network, including a gateway computer, 
a data storage connected to a network that is further con- 
nected to the gateway ComputerLand a mobile client having 
a database, a method of synchronizing the client database 
and the data storage during a non-persistent connection, the 5 
method comprising the steps of: 

connecting the mobile client to the gateway computer; 
manipulating the client database by commands received 

from the gateway computer; 
accessing the data storage by the gateway computer via 

the network; 

updating the data storage responsive to the manipulation 

by the gateway computer; and 
disconnecting the client from the gateway computer. is 

12. The method of claim 11, additionally comprising the 
step of updating the client database. 



14 

13. The method of claim 11, wherein the manipulating 
step includes querying the client database. 

14. The method of claim 11, wherein the manipulating 
step includes removing data from the client database. 

15. The method of claim 11, wherein the data storage 
comprises a mail server so that the mobile client can access 
electronic mail. 

16. The method of claim 11, wherein the gateway com- 
puter is persistently connected to the data storage. 

17. The method of claim U, wherein the network com- 
prises a local area network. 

18. The method of claim 11, wherein the network com- 
prises a wide area network. 

19. The method of claim 18, wherein the wide area 
network is the Internet. 

***** 
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